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Abstract 


This document defines a new report block type within the framework of 
RTP Control Protocol (RTCP) Extended Reports (XRs). One of the 
initial XR report block types is the Loss Run Length Encoding (RLE) 
Report Block. This report conveys information regarding the 
individual Real-time Transport Protocol (RTP) packet receipt and loss 
events experienced during the RTCP interval preceding the 
transmission of the report. The new report, which is referred to as 
the Post-repair Loss RLE report, carries information regarding the 
packets that remain lost after all loss-repair methods are applied. 
By comparing the RTP packet receipts/losses before and after the loss 
repair is completed, one can determine the effectiveness of the loss- 
repair methods in an aggregated fashion. This document also defines 
the signaling of the Post-repair Loss RLE report in the Session 
Description Protocol (SDP). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5725. 
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Les 


Introduction 


The RTP Control Protocol (RTCP) is the out-of-band control protocol 
for applications that are using the Real-time Transport Protocol 
(RTP) for media delivery and communications [RFC3550]. RTCP allows 
RTP entities to monitor data delivery and provides them minimal 
control functionality via sender and receiver reports as well as 
other control packets. [RFC3611] expands the RTCP functionality 
further by introducing the RTCP Extended Reports (XRs). 


One of the initial XR report block types defined in [RFC3611] is the 
Loss Run Length Encoding (RLE) Report Block. This report conveys 
information regarding the individual RTP packet receipt and loss 
events experienced during the RTCP interval preceding the 
transmission of the report. However, the Loss RLE in an RTCP XR 
report is usually collected only on the primary source stream before 
any loss-repair method is applied. Once one or more loss-repair 
methods, e.g., Forward Error Correction (FEC) [RFC5109] and/or 
retransmission [RFC4588], are applied, some or all of the lost 
packets on the primary source stream may be recovered. However, the 
pre-repair Loss RLE cannot indicate which source packets were 
recovered and which are still missing. Thus, the pre-repair Loss RLE 
cannot specify how well the loss repair performed. 


This issue can be addressed by generating an additional report block 
(within the same or a different RTCP XR report), which reflects the 
packet receipt/loss events after all loss-repair methods are applied. 
This report block, which we refer to as the post-repair Loss RLE, 
indicates the remaining missing, i.e., unrepairable, source packets. 
When the pre-repair and post-repair Loss RLES are compared, the RTP 
sender or another third-party entity can evaluate the effectiveness 
of the loss-repair methods in an aggregated fashion. To avoid any 
ambiguity in the evaluation, it is RECOMMENDED that the post-repair 
Loss RLE be generated for the source packets that have no further 
chance of being repaired. If the loss-repair method(s) may still 
recover one or more missing source packets, the post-repair Loss RLE 
SHOULD NOT be sent until the loss-recovery process has been 
completed. However, a potential ambiguity may result from sequence- 
number wrapping in the primary source stream. Thus, the Post-repair 
Loss RLE reports may not be delayed arbitrarily. In case of an 
ambiguity in the incoming reports, it is the sender’s or the 
monitoring entity’s responsibility to understand which packets the 
Post-repair Loss RLE report is related to. 


Similar to the pre-repair Loss RLE, the post-repair Loss RLE conveys 
the receipt/loss events at the packet level and considers partially 
repaired packets as unrepaired. Thus, the methods that can partially 
recover the missing data SHOULD NOT be evaluated based on the 
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information provided by the Post-repair Loss RLE reports since such 
information may underestimate the effectiveness of such methods. 


Note that the idea of using pre-repair and post-repair Loss RLEs can 
be further extended when multiple sequential loss-repair methods are 
applied to the primary source stream. Reporting the Loss RLEs before 
and after each loss-repair method can provide specific information 
about the individual performances of these methods. However, it can 
be a difficult task to quantify the specific contribution made by 
each loss-repair method in hybrid systems, where different methods 
collectively work together to repair the lost source packets. Thus, 
in this specification we only consider reporting the Loss RLE after 
all loss-repair methods have been applied. 


This document registers a new report block type to cover the post- 
repair Loss RLE within the framework of RTCP XR. Applications that 
are employing one or more loss-repair methods MAY use Post-repair 
Loss RLE reports for every packet they receive or for a set of 
specific packets they have received. In other words, the coverage of 
the post-repair Loss RLES may or may not be contiguous. 


2. Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Post-Repair Loss RLE Report Block 


The Post-repair Loss RLE Report Block is similar to the existing Loss 
RLE Report Block defined in [RFC3611]. The report format is shown in 
Figure 1. Using the same structure for reporting both pre-repair and 
post-repair Loss RLEs allows the implementations to compare the Loss 
RLEs very efficiently. 
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0 1 2 3 
012345678901234567890123456789 021 
+-+-+-+-+-+-+-+-+-+-+-+ +H 

| BT=10 | rsvda. | T | block length 

+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| SSRC of source | 
+-+-+-+-+-+-+-+-+-+-+- +++ 
| begin_seq | end_seq | 
+-+-+-+-+-+-+-+-+-+-+-+-+ +H 
| chunk 1 | chunk 2 | 
+-+-+-+-+-+-+-+-+-+-+-+-+ ++ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| chunk n-1 | chunk n 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: Format for the Post-repair Loss RLE Report Block 


o block type (BT): 8 bits 
A Post-repair Loss RLE Report Block is identified by the constant 
LOs 


o rsvd.: 4 bits 
This field is reserved for future definition. In the absence of 
such definition, the bits in this field MUST be set to zero and 
MUST be ignored by the receiver. 


o thinning (T): 4 bits 
The amount of thinning performed on the sequence-number space. 
Only those packets with sequence numbers 0 mod 2^T are reported by 
this block. A value of 0 indicates that there is no thinning and 
all packets are reported. The maximum thinning is one packet in 
every 32,768 (amounting to two packets within each 16-bit sequence 
space). 


If thinning is desired, it is RECOMMENDED to use the same thinning 
value in the Pre-repair and Post-repair Loss RLE reports. This 
will allow easier report processing and correlation. However, 
based on the specific needs of the application or the monitoring 
entity, different values of thinning MAY be used for Pre-repair 
and Post-repair Loss RLE reports. 


o block length: 16 bits 


The length of this report block, including the header, in 32-bit 
words minus one. 
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o SSRC of source: 32 bits 
The SSRC of the RTP data packet source being reported upon by this 
report block. 


o begin_seq: 16 bits 
The first sequence number that this block reports on. 


o end_seq: 16 bits 
The last sequence number that this block reports on plus one. 


o chunk i: 16 bits 
There are three chunk types: run length, bit vector, and 
terminating null. These are defined in Section 4 of [RFC3611]. 
If the chunk is all zeroes, then it is a terminating null chunk. 
Otherwise, the left-most bit of the chunk determines its type: 0 
for run length and 1 for bit vector. 


Note that the sequence numbers that are included in the report refer 
to the primary source stream. 


When using Post-repair Loss RLE reports, the amount of bandwidth 
consumed by the detailed reports should be considered carefully. The 
bandwidth usage rules, as they are described in [RFC3611], apply to 
Post-repair Loss RLE reports as well. 


4. Session Description Protocol Signaling 


A new parameter is defined for the Post-repair Loss RLE Report Block 
to be used with Session Description Protocol (SDP) [RFC4566] using 
the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the 
following syntax within the "rtcp-xr" attribute [RFC3611]: 


pkt-loss-rle-post = "post-repair-loss-rle" ["=" max-size] 


max-size 1*DIGIT ; maximum block size in octets 
Refer to Section 5.1 of [RFC3611] for a detailed description and the 
full syntax of the "rtcp-xr" attribute. The "pkt-loss-rle-post" 
parameter is compatible with the definition of "format-ext" in the 
"rtcp-xr" attribute. 


5. Security Considerations 
The security considerations of [RFC3611] apply in this document as 


well. Additional security considerations are briefly mentioned 
below. 
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An attacker who monitors the regular Pre-repair Loss RLE reports sent 
by a group of receivers in the same multicast distribution network 
may infer the network characteristics (Multicast Inference of Network 
Characteristics). However, monitoring the Post-repair Loss RLE 
reports will not reveal any further information about the network. 
Without the regular Pre-repair Loss RLE reports, the Post-repair ones 
will not be any use to attackers. Even when used with the regular 
Pre-repair Loss RLE reports, the Post-repair Loss RLE reports only 
reveal the effectiveness of the repair process. However, this does 
not enable any new attacks, nor does it provide information to an 
attacker that could not be similarly obtained by watching the RTP 
packets fly by himself, performing the repair algorithms and 
computing the desired output. 


An attacker may interfere with the repair process for an RTP stream. 
In that case, if the attacker is able to see the post-repair Loss 
RLEs, the attacker may infer whether or not the attack is effective. 
If not, the attacker may continue attacking or alter the attack. In 
practice, however, this does not pose a security risk. 


An attacker may put incorrect information in the regular Pre-repair 
and Post-repair Loss RLE reports such that it impacts the proactive 
decisions made by the sender in the repair process or the reactive 
decisions when responding to the feedback messages coming from the 
receiver. A sender application should be aware of such risks and 
should take the necessary precautions to minimize the chances for 
(or, better, eliminate) such attacks. 


Similar to other RTCP XR reports, the Post-repair Loss RLE reports 
MAY be protected by using the Secure RTP (SRTP) and Secure RTP 
Control Protocol (SRTCP) [RFC3711]. 


6. IANA Considerations 


New block types for RTCP XR are subject to IANA registration. For 
general guidelines on IANA considerations for RTCP XR, refer to 
[RFC3611]. 


This document assigns the block type value 10 in the RTCP XR Block 
Type Registry to "Post-repair Loss RLE Report Block". This document 
also registers the SDP [RFC4566] parameter "post-repair-loss-rle" for 
the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. 
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The contact information for the registrations is: 


Ali Begen 
abegen@cisco.com 


170 West Tasman Drive 
San Jose, CA 95134 USA 
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